はじめに # アジャイルグループの石田です。 以前掲載した スクラムマスターのAI活用を考える の連載で、透明性・検査・適応の三本柱をAIで強化するアプローチを紹介してきました。 今回はその実践編として、私が現在のプロジェクトで実践している、AIの発信を起点にデイリースクラムを進める取り組みを紹介します。 ここまで紹介してきたAI活用は、あくまで人間が「AIを使いに行く」ものでした。 分析してほしいデータがあるときにAIに相談する、文字起こしを使ってレトロスペクティブの評価をするといった使い方では、発信の起点は常に人間側にあります。 しかし私が目指しているのは、その関係を逆転させた世界です。 AIがチームの状態を検査して発信し、人間がその結果を起点にスクラムイベントを進めていく。 本記事では、その第一歩としてデイリースクラムで実践している取り組みを具体的に紹介します。 進捗報告になりがちなデイリースクラム # 多くのチームで、デイリースクラムは形骸化しがちです。 「昨日やったこと、今日やること、困っていること」を順番に共有するだけの進捗報告会になり、15分をなんとなく消化して終わってしまうチームも少なくないでしょう。 本来デイリースクラムは、単なる作業報告の場ではありません。 スプリントゴールに対して自分たちが順調に進んでいるかを検査し、必要であれば計画を適応させる場であるべきです。 しかし、この「スプリントゴールへの検査と適応」を毎日きちんと行うのは簡単ではありません。 昨日から今日にかけてチケットの状態がどう変わったのか、その変化がスプリントゴール達成にとって良い兆候なのか悪い兆候なのかを、人間が毎朝正確に把握するのは負荷が高いからです。 そこでAIの出番です。 チケットの日々の変化を蓄積・分析し、スプリントゴールとの関係を客観的に評価します。 実践：GASでチケット履歴を蓄積し、Geminiで分析する # 私が実践している仕組みは、大きく2つのステップで構成されています。 Google Apps Script (GAS) で、現在のスプリントにあるJiraチケットとそれに紐づくサブタスクの状態を毎日取得し、Googleドキュメントに時系列で蓄積する 蓄積された履歴をGeminiに分析させ、スプリントゴールへの検査結果を出力させる Geminiによる分析結果を情報源としてデイリースクラムを実施する ステップ1：GASでチケットの日次履歴を蓄積する # まず、Jira APIを通じてGoogleドキュメントにJiraのデータを記録していくGASを用意します。GASコードの作成自体も、以前の記事と同様に生成AIを使用します。 ドキュメントの内容は、まず冒頭に現在進行中のスプリントのスプリントゴールを書き、そのあとはスプリントに含まれるストーリーやタスクなどのチケットと、それに紐づくサブタスクの変更履歴を毎日追記していきます。 サブタスクの変化も追うことでデータ量は増えてしまいますが、実際の作業の進み具合や滞留を捉えることができます。 実際にJiraから取得している内容は、おおむね以下のようなものです。 === 2026-08-05 のスナップショット === sprint_name: スプリント 21 sprint_goal: ユーザー通知機能をリリース可能な状態にする target_date: 2026-08-14 id: prj-1421 - 通知設定のデータモデル定義 status: Done assignee: 田中 story_points: 2 change_log: 2026-08-13 15:23 status(InProgress -> Done) id: prj-1422 - 設定更新APIエンドポイントの実装 status: In Progress assignee: 田中 story_points: 1 change_log: 2026-08-13 15:45 status(To Do -> InProgress) ステップ2：Geminiで検査・適応の観点から分析する # 蓄積したドキュメントを、デイリースクラム前にGeminiに分析させます。 システムプロンプトをカスタム指示としてGemに登録しておくと、毎朝同じ観点で安定した分析を得られて便利です。 分析結果をデイリースクラムで利用するため、特に下記の内容が重要になります。 スプリントゴールの現在地 ：チケットやサブタスクの変更履歴とスプリントゴールをAIが分析することで、スプリントゴールの達成に対して開発が今どのような状態にあるかを検査します。 メンバー別・本日のアップデート＆問いかけ ：チケットにアサインされているメンバーごとに直近の作業状況を整理し、その状況を元に、スプリントゴールの達成をブロックしている要素がないかなどをAIが具体的に問いかけます。 実際のデイリースクラムでは、これらの情報を元に各メンバーの作業状況を確認し、AIが行ったスプリントゴールに対する検査の妥当性を確認したうえで、必要であれば適応を行います。 これにより、デイリースクラムをただの進捗報告に終わらせず、メンバーが自然とスプリントゴールに向かって一丸となれます。 作成したGemのプロンプトの一部を紹介します。 # 役割 あなたは優秀なアジャイル・スクラムマスターであり、デイリースクラムのファシリテーターです。 提示されるJiraのログを読み解き、チームがスプリントゴールを達成するために、 本日のデイリースクラムで確認すべきポイントを整理して、会議の起点となる発言を生成してください。 # 入力データの特性・運用ルール （中略） # 思考プロセス・指示 （中略） # 出力フォーマット 以下の構成で出力してください。 デイリースクラムの場でそのまま上から順に気持ちよく読み進められる、 プロフェッショナルかつ親しみやすいトーンを徹底してください。 皆さんおはようございます。本日のデイリースクラムを始めます。 ## スプリントゴールの現在地 [ゴール項目]:（進捗感や残りのタスク量・作業タイプを踏まえた分析を1〜2行でコンパクトに記述） ## メンバー別・本日のアップデート＆問いかけ [メンバー名 / またはペアプロ等の場合は連名] 直近の状況:（直近の稼働日における、担当チケットの動きやchangelogの要約） AIからの問いかけ:（状況や作業タイプを踏まえ、ブロックしている要素がないかなど具体的に問いかける文章） AIの発信からスクラムが動く # この仕組みの本質は、デイリースクラムの起点がAIの発信になることにあります。 従来であれば、メンバーが一人ずつ状況を報告し、その内容を聞いて誰かが問題に気づく、という流れでした。 しかしこの実践では、デイリースクラムが始まる前にGeminiがすでにスプリントゴールへの検査を終えています。 チームはAIが提示した「今日議論すべき論点」を出発点にデイリースクラムを始められます。 「AIが問いかけている、田中さんが担当するAPI実装のブロッカーについて、まず話しましょう」というように、最も重要な検査と適応から会話がスタートするのです。 これは、私が目指す「AIを使いに行くのではなく、AIの発信からスクラムが動いていく世界」の始まりです。 人間はAIに問い合わせる手間から解放され、AIが差し出した気づきに対して「どう適応するか」という、人間にしかできない意思決定に集中できます。 スクラムマスターとしての展開 # 私はこの仕組みを作り、チームに展開しました。最初の2週間ほどは、データとプロンプトを調整しながら私自身がGeminiで分析を回し、その結果をSlackで共有するテスト運用を行いました。 ある程度安定して運用できるようになった段階で、継続するかどうかをチームに委ね、現在はチームが自律的にこの仕組みを使っています。 スクラムマスターとしては、デイリースクラムの検査と適応を強化する選択肢をチームに示したうえで、実際に使うかどうかはチームに任せることが大切だと思います。 AI起点のデイリースクラムによるチームの変化 # 実際のデイリースクラムは、下記のような流れで運用しています。なお、チームは全メンバーがフルリモートで稼働しています。 当日のファシリテート担当がデイリースクラム前にGeminiを動かし、結果をSlackに投稿する。 分析結果をもとに、まずスプリントゴールの現在地を把握し、続いてAIが示したメンバー別の問いかけを確認する。 今のままでスプリントゴールを達成できそうかを、「はい」「いいえ」「微妙」の3つのいずれかでZoomのリアクションとして示す。 「いいえ」や「微妙」があった場合は、その内容を確認し、必要に応じて作業計画を変更する。 デイリースクラムのプラクティスとして「スプリントゴールチェックイン」というものがあります。 これは、デイリースクラムの冒頭で「このままいけばスプリントゴールを達成できそうか？」を開発者全員に問いかけることで、スプリントゴールへの検査を強化するというものです。 上記の手法は、これにAIによる補助を加えることで、スプリントゴールへの検査と適応をさらに強化した形になっています。 これまでのチームでは、デイリースクラムでそれぞれの作業状況の共有はできていたものの、その作業がスプリントゴールに対して正しく向いているのかを検査できていない、という問題がありました。 それがAIの分析によって作業状況の透明性が高まり、さらにスプリントゴールへの検査までAIが担うことで、その結果を踏まえた適応の議論がチーム内で自然と生まれるようになりました。 想定される疑問 # Geminiを手動で動かしているのなら、AI起点とは言えないのでは？ # AIの発信を起点にすると言いながら、結局Geminiを人間が動かしているのであれば、起点はやはり人間なのではないかという疑問です。 これはその通りで、本来であればAPIなどを使って分析を自動化し、デイリースクラム前に毎日Slackなどへ検査結果が投稿される形が理想だと思います。 しかし今回の手法は、私が携わっているプロジェクトではAIに関するAPIが使用できない、という制約条件を加味したうえでのものでした。 本記事を参考に実践してみたい方は、ぜひより高度な自動化に挑戦してみてください。 Jiraに組み込まれたAIでチケットの分析は可能なのでは？ # Jiraには現在、Rovoと呼ばれるAIエージェントが組み込まれています。これを使えば、ここまでの手間をかけずともスプリントの分析は可能でしょう。 しかしプロンプトの自由度や出力結果の安定性という面を考えると、今回のようなシステムプロンプトを用いた方法は十分に有用だと考えています。 実践する際の注意点 # AIの検査は「たたき台」である # Geminiの検査結果は非常に有用ですが、あくまでチケットのデータから読み取れる範囲の分析です。 チケットには表れないコンテキスト、たとえば「このチケットが止まっているのは意図的に優先度を下げたから」といった背景までは把握できません。 AIの発信を出発点にしつつ、その指摘が的を射ているかをチームが判断する。この対話こそがデイリースクラムの価値であり、AIの分析を鵜呑みにすることではありません。 ドキュメントの肥大化には注意 # JiraチケットのChangelogを含むデータを毎日書き込んでいると、ドキュメントのデータ量、つまりAIへの入力量が肥大化していきます。 スプリントごとに新しいドキュメントに切り替える、前日に変更があったものだけを書き込むといった、データ量を抑える工夫が必要です。 仕組み自体もふりかえる # この仕組みがチームの役に立っているかどうかも、定期的にふりかえる対象です。 AIの発信が的外れだったり、かえって議論をミスリードしたりするようであれば、プロンプトや蓄積するデータの内容を見直します。 またスクラムマスターとしては仕組みを提供するまでが役割です。チームにとって意味をなさない、運用負荷が高すぎるといった結論に至ったのであれば、利用を停止する判断も必要です。 まとめ # 本記事では、スクラムマスターのAI活用を考える連載の実践編として、デイリースクラムをAI起点で回す取り組みを紹介しました。 GASでJiraチケットとサブタスクの日次履歴をGoogleドキュメントに蓄積する Geminiのカスタム指示（Gem）で、スプリントゴールの現在地とメンバー別の問いかけを毎朝生成する その分析結果を起点にデイリースクラムを始め、スプリントゴールチェックインと組み合わせて検査と適応を強化する この仕組みによって、これまで作業報告に終始しがちだったデイリースクラムが、スプリントゴールへの検査と、それを踏まえた適応を話し合う場へと変わりました。 作業状況の透明性、スプリントゴールへの検査、ゴール達成に向けた適応という、スクラムの三本柱をAIによって着実に強化することができます。 まだ道半ばの取り組みですが、AIがチームの状態を検査し続け、人間はその気づきをもとに適応へ集中する。 そんなAI起点のスクラムの世界を、これからも実践を通じて探求していきたいと思います。

1. はじめに こんにちは。株式会社medibaでエンジニアをしている野口です。 突然ですが皆さんは、良かれと思って行った業務改善やプロダクトの施策で、 「で、それって結局どれくらい効果があったの？」 と聞かれて言葉に詰まった経験はありませんか？ 少し前の話になりますが、私は社内の「障害レポート」の運用を大きく刷新する業務を担当しました。それまでは手動でデータを集計し月に1回更新していたものを、GAS（Google Apps Script）を用いて日次で自動集計・更新されるシステムへと作り変えたのです。 「これで運用コストも下がったし、毎日最新の障害情報やKPIが見られるようになった

GASのコアサービス化で期待したい管理者向け機能 まず期待したいのは、組織内GASの一覧化 最も期待したいのは、管理者が組織内で作成・実行されているGASを一覧で把握できる機能です。これまでGASは、個人のマイドライブ上に作成されたり、スプレッドシートに紐づくコンテナバインドスクリプトとして作成されたりすることが多く、管理者が全体像を把握しにくいという課題がありました。